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(1) Real Party In Interest 

The statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 
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(8) Evidence Relied Upon 

Liou, WO 99/46702, published internationally September 16, 1999. 
Dalrymple et al., US 6,976,094 Bl, issued on Dec. 13, 2005, and filed on Sep 

2000. 

Handley et al., RFC 2327, April 1998. 
Vilander, US 7,193,987 B2. 
Kumar et al., US 6,006,253. 
Crandall et al., US 2002/0107040 Al. 
Agresta et al., US 2002/0091848 Al. 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claim Rejections - 35 USC S 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 1-2, 4-6, 8-19, 23-25, 30-33 and 42-45 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Liou (WO 99/46702) in view of Dalrymple et al. (hereinafter 
Dalrymple, US 6,976,094 Bl), further in view of Handley et al. (hereinafter Handley, RFC 2327: 
SDP, April 1998), and further in view of Vilander (US 7,193,987 B2). 



.21, 
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As per claim 1, Liou discloses a method comprising: 

distributing a start playback request from the host terminal to the guest terminal, wherein 
the start playback request directs the guest terminal to being a playback session of a media file 
that is locally stored in the guest terminal in synchronization with a beginning of the playback 
session at the host terminal (fig. 10: joining and distributing play request, user 1, user 2, pg. 18 
L4-32, pg. 14 LI 2-32: receiving messages and distributing to clients); 

receiving an action request from the guest terminal requesting a playback action (fig. 10: 
receiving pause action from the terminal, pg. 18 L4 to pg. 19 LI 3: VCR commands); and 

sending the playback action request received from the guest terminal to the host terminal 
(fig. 10: sending the pause message). 

However, Liou does not expressly disclose the process of receiving a first media 
playback invite request initiated by a host wireless terminal, the first media playback invite 
request including: information sufficient to identify at least one guest wireless terminal, an 
identification of a pre-existing playable media file, and a playback option enabling the guest 
terminal to request different types of playback actions in connection with playback of the 
identified media file; transmitting a second media playback to the guest wireless terminal 
subsequent to receipt of the first media playback invite request, wherein the media playback 
invite request includes a playback option and the process of relaying a media playback accept 
response from the guest terminal to the host terminal (a typical session set up or initiation 
processes). 

Dahymple explicitly discloses a call set-up method during conferencing comprising the 
process of receiving a first media playback invite request initiated by a host terminal, the first 
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media playback invite request including: information sufficient to identify at least one guest 
terminal, an identification of a pre-existing playable media file (fig. 2 step 100: Invite request is 
send to proxy server which identifies the recipient through location server using information 
from the invite request message) transmitting a second media playback to the guest wireless 
terminal subsequent to receipt of the first media playback invite request (fig. 2 item #106) and 
the process of relaying a media playback accept response from the guest terminal to the host 
terminal (fig. 2 step #100, 106, 108, 110, fig. 4, col. 3 L50 to col. 4 L46, col. 5 L23-50: the OK 
response message in SIP protocol by a node/terminal is to convey to the client that the action was 
successfully received, understood and accepted). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to invite the participants 
or users to join a session or to engage in a session. 

One of ordinary skilled in the art would have been motivated because this would have 
established a communication session between two computers through invitations that invites 
the users to join or engage in a session (Dalrymple: col. 3 L50 to col. 4 LI 8). 

However, Liou in view of Dalrymple does not disclose the media playback invite request 
including a playback option enabling the guest terminal to request different types of actions (the 
feature is obvious in SIP and SDP protocols). 

Handley explicitly discloses a session description protocol (SDP) including the process of 
sending the invitations to the users, wherein the invitations includes various fields comprising a 
playback option field for enabling the guest terminal to request different types of actions, i.e. 
enabling the receiver for interactive conferencing/meeting, i.e. for sending the 
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actions/data/requests (pg. 23: a= sendrecv field enables the users to send and receive 
data/requests/information, etc.). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou and Dalrymple in view of Handley in order to include a 
playback option in the invitation in order to enable the invited users for interactive conferences, 
wherein the invited users can send various types of data/requests enabled by the playback option 
to the host terminal. 

One of ordinary skilled in the art would have been motivated because this would have 
enabled the receivers, i.e. users, to engage in an interactive conference (Handley: pg. 23). 

However, LIOU, Dalrymple and Handley do not disclose the method wherein the 
terminals are wireless terminals. 

Vilander explicitly discloses setting up communications between wireless terminals using 
the SIP protocols (fig. 4: MS, and col. 4 L20-38). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify LIOU, Dalrymple and Handley in view of Vilander in order to 
enable the wireless devices to engage in a playback session. 

One of ordinary skilled in the art would have been motivated because it would enabled 
users to participate in a communication session using the mobile devices, See also Dalrymple: 
col. 3 L50 to col. 4 L21, Vilander: col. 2 L59-67, col. 4 L60-67. 

As per claim 2, Liou discloses the method further comprising distributing the action 
request to another terminal during the playback session (pg. 6 L18-27, pg. 14 L12-33: receives 
action(s) and distributes to all session manager associated with the users, fig. 10). 
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As per claim 4, Liou discloses the method wherein the action request is selected from the 
group consisting of a rewind request, a pause playback request, a fast forward request, a textual 
comment request, and a user-specified internal effect algorithm to modify audio or video of the 
media file (pg. 11 L21-32, pg. 12 L12-25, fig. 4, fig. 10: pause action). 

As per claim 5, Liou discloses the method comprising distributing a stop playback 
request from the host terminal to the guest terminal in response to the host user terminating the 
playback session (pg. 11 L21-32, pg. 12 LI -25: a stop button will stop the playback session, pg. 
14 L12-32: distributing actions to the rest of the clients). 

As per claim 6, Liou discloses the method further comprising storing an internal time in 
response to distributing a start playback request from the host terminal to the guest terminal, 
wherein the start playback request directs the guest terminal to being a playback session of a 
media file that is locally stored in the guest terminal in synchronization with the host terminal 
(pg. 7 LI 0-14) and providing an elapsed time since distributing the start playback request to third 
terminal when the third terminal joins the playback session during the playback session (pg. 6 
L3-27: delaying, pg. 14 L12-24). 

As per claim 8, Liou discloses the method further comprising receiving a stop playback 
request from the guest terminal in response to the guest user withdrawing from the playback 
session (pg. 11 L21-32, pg. 12 LI -25: a stop button will stop the playback session); and 
removing a session entry that is associated with the guest terminal, wherein the session entry 
indicates participation of the guest terminal in the playback session (pg. 14 LI 2-23: managing 
state of the conference). 
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As per claim 9, Liou discloses the method further comprising receiving a stop playback 
request from the host terminal in response to the host user ending the playback session and 
terminating the playback session in response to receiving a stop playback request (pg. 1 1 L21-32, 
pg. 12 LI -25: a stop button will stop the playback session). 

As per claim 10, Liou discloses the method further comprising instructing the guest 
terminal to modify the media file in accordance with a modification file during the playback 
session (fig. 4, pg. 7 L29 to pg. 8 L6: client loads one of video and recorded annotation file in a 
user interface for performing annotation of the video file, i.e. annotating/modifying the media 
file in accordance with the recorded annotation file, pg. 12 L12-25: recording annotations in 
accordance with a text edit window, pg. 19 L9-13: annotate during the playback of recorded 
annotation file, commanding to draw annotation based on the received annotation record, i.e. a 
modification file). 

As per claim 13, Liou discloses the computer readable medium further comprising 
instructions to perform distributing a stop playback request from the host terminal to the guest 
terminal (fig. 10). 

However, Liou does not disclose distributing a stop playback request to at least one other 
terminal in response to host terminal user terminating the playback session. 

Dalrymple discloses multiple guest terminals and//or users engaging in playback session 
utilizing SIP protocol (col. 4 L31-47). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to distribute the stop 
request to at least one other terminal. 
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One of ordinary skilled in the art would have been motivated because it would have 
enabled playback and/or conference session with multiple users (Dalrymple: col. 4 L31-47). 
As per claim 14, Liou discloses a method comprising: 

Distributing/sending a start playback request from the host terminal to the guest terminal, 
wherein the start playback request directs the guest terminal to being a playback session of a 
media file that is locally stored in the guest terminal in synchronization with a beginning of the 
playback session at the host terminal (fig. 10: joining and distributing play request, user 1, user 2, 
pg. 18 L4-32, pg. 14 L12-32: receiving messages and distributing to clients); 

receiving an action request from the guest terminal, wherein the action request includes 
the playback option (fig. 10: receiving pause action from the terminal, pg. 18 L4 to pg. 19 L13: 
VCR commands); and 

sending the playback option received from the guest terminal to the host terminal (fig. 10: 
sending the pause message). 

However, Liou does not expressly disclose the process of sending a media playback 
invite request to at least one guess wireless terminal from a host wireless terminal, wherein the 
media playback invite request includes information sufficient to identify at least one guest 
wireless terminal, an identification of a pre-existing playable media file, and a playback option 
enabling the guest terminal to request different types of playback actions in connection with 
playback of the identified media file and the process of receiving a media playback accept 
response from the guest terminal to the host terminal in response to invite request (a typical 
session set up or initiation processes). 
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Dalrymple explicitly discloses a call set-up method during conferencing comprising the 
process of receiving a first media playback invite request initiated by a host terminal, the first 
media playback invite request including: information sufficient to identify at least one guest 
terminal, an identification of a pre-existing playable media file (fig. 2 step 100: Invite request) 
and the process of receiving a media playback accept response from the guest terminal to the 
host terminal (a typical session set up or initiation processes, fig. 2 step #100, 106, 108, 110, fig. 
4, col. 3 L50 to col. 4 L46, col. 5 L23-50: the OK response message in SIP protocol by a 
node/terminal is to convey to the client that the action was successfully received, understood and 
accepted). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to set-up the session. 

One of ordinary skilled in the art would have been motivated because this would have 
established a communication session between two computers through invitations (Dalrymple: 
col. 3 L50 to col. 4 L21). 

However, Liou in view of Dalrymple does not disclose the media playback invite request 
including a playback option enabling the guest terminal to request different types of actions (the 
feature is obvious in SIP and SDP protocols). 

Handley explicitly discloses a session description protocol (SDP) including the process of 
sending the invitations to the users, wherein the invitations includes various fields comprising a 
playback option field for enabling the guest terminal to request different types of actions, i.e. 
enabling the receiver for interactive conferencing, i.e. for sending the actions (pg. 23: a= 
sendrecv field enables the users to send and receive data). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou and Dalrymple in view of Handley in order to include a 
playback option in the invitation. 

One of ordinary skilled in the art would have been motivated because this would have 
enabled the receivers, i.e. users, to engage in an interactive conference (Handley: pg. 23). 

However, LIOU, Dalrymple and Handley do not disclose the method wherein the 
terminals are wireless terminals. 

Vilander explicitly discloses setting up communications between wireless terminals using 
the SIP protocols (fig. 4: MS, and col. 4 L20-38). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify LIOU, Dalrymple and Handley in view of Vilander in order to 
enable the wireless devices to engage in a playback session. 

One of ordinary skilled in the art would have been motivated because it would have 
provided playback session to the wireless devices. 

As per claim 30, Liou discloses the method wherein the media file is locally stored on the 
guest terminal for playback (pg. 6 L3-10). 

As per claim 43, LIOU in view of Dalrymple discloses the apparatus wherein the media 
playback invite request includes information sufficient to identify multiple guest wireless 
terminals (col. 4 L3-46). 

As per claims 11-12, 15-19, 23-25, 31-33, 42 and 44-45, they do not teach or further 
define over the limitations in claims 1-2, 4-6, 8-10, 13, 14 and 30. Therefore, claims 11-12, 15- 
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19, 23-25, 31-33, 42 and 44-45 are rejected for the same reasons as set forth in claims 1-2, 4-6, 
8-10, 14 and 30. 

Claims 36, 39 and 46-47 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Liou (WO 99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), 
further in view of Kumar et al. (hereinafter Kumar, US 6,006,253), and further in view of 
Vilander(US 7,193,987 B2). 

As per claim 36, Liou discloses an apparatus (i.e. a host and/or guest terminal, pg. 10 Ll- 
24, for use in a synchronous media playback system) comprising: 

a processor (pg. 10 LI -24); and 

memory (pg. 6 L3-10) storing computer-executable instructions that when executed (pg. 
10 Ll-24, fig. 1: plurality of host terminals), perform: 

receiving at the apparatus a start playback request, wherein the start playback request 
begins a playback session of the identified media file in synchronization with a beginning of the 
playback session at a host terminal (fig. 10: joining and distributing play request, user 1, user 2, 
pg. 18 L4-32, pg. 14 LI 2-32: receiving messages and distributing to clients); 

subsequent to receiving the start playback request, transmitting an action request to the 
server, wherein the action request includes the playback option (fig. 10: receiving pause action 
from the terminal, pg. 18 L4 to pg. 19 L13: VCR commands and sending the pause message). 

However, Liou does not expressly disclose the process of receiving a media playback 
invitation at the apparatus from a server via a wireless channel, wherein the media playback 
invitation includes an identification of a pre-existing playable media file, a playback option 
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enabling the apparatus to request different types of playback actions in connection with playback 
of the identified media file and responsive to receiving the media playback invitation, 
transmitting a media playback accept response to the server, wherein if the apparatus does not 
have the media file, the apparatus downloads the media file before transmitting the media 
playback accept response. 

Dalrymple explicitly discloses a call set-up method during conferencing comprising the 
process of sending an invite request message from the host terminal to the guest terminal through 
a central server, i.e. receiving at the apparatus an invitation from the server, wherein the 
invitation includes an identification of a pre-existing playable media file (SIP uses SDP to 
describe the session including identification of media file) and responsive to receiving the media 
playback invitation, transmitting a media playback accept response to the server (i.e. a standard 
approach for setting up a communication session and sending invitations in SIP protocol, fig. 2 
step #100, 106, 108, 110, fig. 4, col. 3 L50 to col. 4 L46, col. 5 L23-50: the OK response 
message in SIP protocol by a node/terminal is to convey to the client that the action was 
successfully received, understood and accepted). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou in view of Dalrymple in order to invite the users and 
receive the response. 

One of ordinary skilled in the art would have been motivated because this would have 
established a communication session between two computers through invitations (Dalrymple: 
col. 3 L50 to col. 4 L21). 
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However, Liou in view of Dalrymple does not disclose the media playback invite request 
including a playback option enabling the guest terminal to request different types of actions and 
the process wherein if the apparatus does not have the media file, the apparatus downloads the 
media file before transmitting the media playback accept response. 

Kumar discloses the SDP comprising sending an announcement, i.e. invitations, 
including a playback option, i.e. field for indicating mode of operation such as sendonly, 
sendrecv or recvonly, enabling the guest terminal to request different types of actions i.e. 
enabling the receiver for interactive conferencing, i.e. for sending the actions (fig. 6 item #650, 
col. 10 LI 1-44), and the process of downloading the media file if the apparatus does not have the 
media file (col. 7 L25-55: note that the invitations and/or announcement enables the user to 
download the slides before and/or after the user transmits the accept response). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou and Dalrymple in view of Kumar in order to include a 
playback option in the invitation and download the media filed before transmitting the accept 
message. 

One of ordinary skilled in the art would have been motivated because this would have 
enabled the receivers, i.e. users, to engage in an interactive conference regarding the media file 
(See claim 1). 

However, LIOU, Dalrymple and Handley do not disclose the process of receiving a 
media playback invitation at the apparatus from a server via a wireless channel. 

Vilander explicitly discloses the process of receiving a media playback invitation at the 
apparatus from a server via a wireless channel (fig. 4: MS, and col. 3 L65 to col. 4 L38). 
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Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify LIOU, Dalrymple and Handley in view of Vilander in order to 
receive the invitation from the server via the wireless channel. 

One of ordinary skilled in the art would have been motivated because it would enabled 
users to participate in a communication session using the mobile devices, See also Dalrymple: 
col. 3 L50 to col. 4 L21, Vilander: col. 2 L59-67, col. 4 L60-67. 

As per claim 38, Liou and Dalrymple discloses the apparatus wherein the processor 
utilizes the communication interface to communicate to a central server, wherein the central 
server receives and forwards invitations and responses between the apparatus and the terminal 
(Liou: pg. 10 Ll-24, pg. 14 L12-32, fig. 1, fig. 10; Dalrymple: fig. 2-4, pg. 16 L21-27). 

As per claim 39, Liou discloses the apparatus wherein the processor includes instructions 
to perform modifying the media file in accordance with a modification file during the playback 
session (fig. 4, pg. 7 L29 to pg. 8 L32: client loads one of video and/or recorded annotation file 
in a user interface for changing the speed and/or performing annotation of the video file, i.e. 
annotating/modifying the media file in accordance with the recorded annotation file, pg. 11 L21- 
32, pg. 12 LI 2-25: recording annotations in accordance with a text edit window, pg. 19 L9-13: 
annotate during the playback of recorded annotation file, commanding to draw annotation based 
on the received annotation record, i.e. a modification file). 

As per claims 46-47, they do not teach or further define over the limitations in claims 36 
and 39. Therefore claims 46-47 are rejected for the same reasons as set forth in claims 36 and 39. 
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Claim 40 is rejected under 35 U.S.C. 103(a) as being unpatentable over Liou (WO 
99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), and further in 
view of Handley et al. (hereinafter Handley, RFC 2327: SDP, April 1998), further in view of 
Vilander (US 7,193,987 B2), and further in view of Kumar et al. (hereinafter Kumar, US 
6,006,253). 

As per claim 40, Liou, Dalrymple, Handley and Vilander discloses the method as in 
claim 1 as set forth above. 

However, Liou, Dalrymple, Handley and Vilander do not disclose the method wherein if 
the guest terminal does not have the media file, the guest terminal downloads the media file 
before sending the media playback accept response. 

Kumar discloses the process of downloading the media file if the apparatus does not have 
the media file (col. 7 L25-55: note that the invitations and/or announcement enables the user to 
download the slides before and/or after the user transmits the accept response). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou, Dalrymple, Handley and Vilander in view of Kumar in 
order to download the media filed before transmitting the accept message. 

One of ordinary skilled in the art would have been motivated because it would have 
enabled the receivers, i.e. users, to engage in an interactive conference regarding the media file. 

Claim 7 is rejected under 35 U.S.C. 103(a) as being unpatentable over Liou (WO 
99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), in view of 
Handley et al. (hereinafter Handley, RFC 2327: SDP, April 1998), further in view of Vilander 
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(US 7,193,987 B2), and further in view of Crandall et al. (hereinafter Crandall, US 
2002/0107040 A 1). 

As per claim 7, Liou, Dalrymple, Handley and Vilander discloses the process of receiving 
a host internal time from the host terminal or the guest terminal, wherein the host internal time is 
derived from a global time (Liou: pg. 6 L3-27, pg. 14 L12-24, pg. 7 L10-14). 

However, Liou, Dalrymple, Handley and Vilander do not expressly disclose the process 
of comparing the host internal time to a guest internal time in order to derive a time difference, 
wherein the guest internal time is derived from the global time; and adjusting transmission of a 
subsequent message to the host terminal or the guest terminal (Liou may inherently teach the 
process). 

Crandall discloses the process of synchronizing messages by determining host time and 
guest time, comparing the host time with the guest time in order to derive time difference, i.e. 
delay, and adjusting the transmission of a subsequent message to the host terminal (fig. 4, fig. 5, 
fig. 7, fig. 9, pg. 2 [0030-0034], pg. 3 [0044-0046], pg. 4 [0047-0057]). 

Therefore it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou, Dalrymple, Handley and Vialnder in view of Crandall in 
order to derive a time difference and adjust the transmission of the messages. 

One of ordinary skilled in the art would have been motivated because it would have 
provided same amount of latency for different users and/or actions (Crandall, pg. 1 [0005]). 

Claims 3 and 41 are rejected under 35 U.S.C. 103(a) as being unpatentable over Liou 
(WO 99/46702) in view of Dalrymple et al. (hereinafter Dalrymple, US 6,976,094 Bl), in view 
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of Handley et al. (hereinafter Handley, RFC 2327: SDP, April 1998), further in view of Vilander 
(US 7,193,987 B2), and further in view of Agresta et al. (hereinafter Agresta, US 2002/0091848 
Al). 

As per claim 3, Liou, Dalrymple, Handley and Vilander do not disclose the process of 
verifying permissions associated with the guest terminal, wherein the sending of the playback 
option received from the guest terminal to the host terminal is responsive to verifying the 
permissions associated with the guest terminal. 

Agresta explicitly teaches the process of verifying the permissions, i.e. authoring account 
before executing the process such as pause, rewind, forward, etc. (fig. 4A step #116, 138, pg. 6 
[0051]). 

Therefore, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was made to modify Liou, Dalrymple, Handley and Vilander in view of Agresta in 
order to verify the permissions of the terminals and/or users before executing any actions. 

One of ordinary skilled in the art would have been motivated because it would have 
verified the access rights of the user. 

As per claim 41, it does not teach or further define over the limitations in claims 3 and 
20. Therefore, claim 41 is rejected for the same reasons as set forth in claims 3 and 20. 
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(10) Response to Argument 

In the Appeal Brief (hereinafter, The Brief), appellant has raised various arguments. The 
Examiner summarizes and addresses each of the argument individually. 
In the Brief, appellant argues in substance that: 

a. Appellants argue the rejection of claims 1-19, 23-25, 30-33, 36 and 39-47 under 
35 USC 1 12, first paragraph (The Brief, pg. 14 VII. A.). 

In response to argument [a], the rejection is withdrawn in view of claim amendments 
made after final action, which were entered in the advisory action 4/27/09. 

b. None of the references provides for a "media playback invite request including a 
playback option enabling the guest wireless terminal to request different types of 
playback options in connection with playback of the identified media file" (The Brief, 
pg. 16, B.). 

In response to argument [b], Examiner respectfully disagrees. 

Initially, It should be noted that "a playback option. . .playback options in connection. . ." 
is not recited in the rejected claim. 

However, It appears that appellant intended to recite "media playback option 
enabling. . .playback actions in connection. . ." 

Independent claim 1, which was amended after final rejection and entered, recites: 

A method comprising: 

receiving a first media playback invite request initiated by a host wireless terminal, the first 
media playback invite request including 

information sufficient to identify at least one guest wireless terminal, 
an identification of a pre-existing playable media file, and 
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a playback option enabling the guest wireless terminal to request different 
types of playback actions in connection with playback of the identified media file; 

transmitting a second media playback invite request to the guest wireless terminal subsequent to 
receipt of the first media playback invite request, wherein the second media playback invite request 
includes the playback option; 

relaying a media playback accept response from the guest wireless terminal to the host wireless 

terminal; 

distributing a start playback request from the host wireless terminal to the guest wireless terminal, 
wherein the start playback request directs the guest wireless terminal to begin a playback session of the 
identified media file in synchronization with a beginning of the playback session at the host wireless 
terminal; 

receiving an action request from the guest wireless terminal-requesting a playback action enabled 
by the playback option; and 

sending the action request received from the guest wireless terminal to the host wireless terminal. 



In the Brief, appellant argues that none of the references disclose or suggest the single 
invite request that includes "information sufficient to identify the at least one guest wireless 
terminal, an identification of a pre-existing playable media file, and a playback option enabling 
the guest terminal to request different types of playback actions in connection with playback of 
the identified media file", e.g. pg. 17, 2nd paragraph. 

In support for the above recitations, appellant specification discloses: 

[25] As was discussed in relation to FIG. 1, the host user initiates a playback session by causing 
terminal 101 to send invite request 201 to messaging server 109. In one variation, invite request 201 
comprises various information fields, including guest user ID, session ID, media file ID, host user ID, 
playback options, playback scheduling, and a flee text string of other media type that explains the invitation 
to the guest users. Playback options give specific guest users permission to request different types of 
actions during the playback session. Table 1 shows information that is contained in the invite request in 
accordance with the exemplary embodiment. With this example, a GSM SMS message is able to transport 
160 characters of text. (Alternatively, a Multimedia Messaging System (MMS) message can be utilized for 
supporting synchronous media and playback messaging.) In the example, the SMS 
message is represented as: . . . 

[31] During the playback session (as initiated by start playback requests 221 and 223), any of 
the active users (host user and guest users) can request a playback action. In order to do so, an active 
user sends an action request (e.g. action request 225) to central server 107. The action request 
message requests one of a number of action types during the playback session, including pause 
playback, rewind, fast-forward, user- specified internal effect algorithm to modify audio or video 
(e.g. altering the audio and video in order to accentuate a favorite actress), or textual comment from 
a user. The first three action types are patterned after actions that are typically associated with an 
audio cassette player or a VCR. The fourth action type is user-specified that can be customized for 
the specific application. As an example, the media player can be instructed to emphasize the dialog of 
a particular actress in a particular scene. As another example, if a user wishes to send a comment to 
the other users, an action request message with textual comment (e.g. "I really like this scene - 
Jane") is sent to central server 107. 
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First, it is noted that the playback option enabling the user to request different types of 
playback actions comprises requesting one of a number of action types during the playback 
session, including pause playback, rewind, fast-forward, user- specified internal effect 
algorithm to modify audio or video (e.g. altering the audio and video in order to accentuate 
a favorite actress), or textual comment from a user. As an example: appellant discloses that 
"if a user wishes to send a comment to the other users, an action request message with 
textual comment e.g. I really like this scene... is sent to the central server. 

Stated another way, one of the playback action may comprise inputting and/or 
sending the textual comment from a user, i.e. inputting and sending the data such as text 
comment from a user. 

PRIOR ART 

Initially, Liou discloses the process of joining a session, distributing a start playback 
request from the host terminal to the guest terminal, receiving an action request such as a pause 
action, from the guest terminal, and sending the action such as the pause action from the guest 
terminal to the host terminal, See fig. 10. 

However, Liou does not disclose the process of sending an invite message to the guest 
terminal including the sufficient information, the identification and the playback option enabling 
the guest terminal to request different types of playback actions. 

But, these functionalities and/or processes, i.e. sending the first and second 
invitations including the sufficient information, the identification and the playback option 
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enabling the guest terminal to request different types of playback options are typical 
processes of a SIP protocol. 

A SIP protocol is an application-layer control protocol for creating, modifying and 
terminating sessions with one or more participants, See RFC 2543, which is incorporated 
by reference in Dalrymple, e.g. col. 3 L51-60. 

Moreover, Dalrymple explicitly discloses the usage of SIP protocol for inviting the other 
computers to begin a playback session of a media file in synchronization, e.g. fig. 2 and col. col. 
3 L50 to col. 4 L46, which are reproduced herein. 
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Stated another way, Dalrymple uses the SIP protocol to invite the other participants to 
join a session or engage in a session by sending an invitation, i.e. the INVITE request and 



receiving an acknowledgement from the invited participants. 
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The Invite request comprises information sufficient to identify at least one invited 
guest terminal. 

For example: A proxy server accepts the invite request from a caller computer and 
contacts a location service server with all or part of the caller's address to determine specific 
address information for the invited callee, e.g. Dalrymple: col. 4 L20-31, which is reproduced 
above, See RFC 2543: SIP protocol, pg. 14 [1.4.4], which is also reproduced below. 

In other words, the invite request provides sufficient information to identify at least one 
guest or invited terminal because the proxy server is capable of identifying the recipient's 
address. 

Although, Dalrymple does not explicitly recite the usage of session description protocol, 
i.e. SDP, the SIP protocol implicitly and/or inherently uses the session description protocol, i.e. 
SDP, to describe a session. 

For example: See RFC 2543: SIP protocol, Pg. 14 [1.4.4]: SIP Invitation, which is 
reproduced herein. 

1.4.4 SIP Invitation 

A successful SIP invitation consists of two requests, INVITE followed by ACK. The INVITE 
(Section 4.2.1) request asks the callee to join a particular conference or establish a two-party conversation. 
After the callee has agreed to participate in the call, the caller confirms that it has received that response by 
sending an ACK (Section 4.2.2) request. If the caller no longer wants to participate in the call, it sends a 
BYE request instead of an ACK. 

The INVITE request typically contains a session description, for example written in SDP 
(RFC 2327 [6]) format, that provides the called party with enough information to join the session... 

The protocol exchanges for the INVITE method are shown in Fig. 1 for a proxy server and in Fig. 
2 for a redirect server. (Note that the messages shown in the figures have been abbreviated slightly.) In Fig. 
i, the proxy server accepts the INVITE request (step i), contacts the location service with all or parts of the 
address (step 2) and obtains a more precise location (step 3). The proxy server then issues a SIP INVITE 
request to the address(es) returned by the location service (step 4). The user agent server alerts the user 
(step 5) and returns a success indication to the proxy server (step. . . 
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The SIP invite request typically contains a session description, written in SDP (RFC 
2327) format that provides the called party enough information to join the session, e.g. See 
RFC 2543, pg. 14 [1.4.4], which is reproduced above. 

More specifically, the SDP provides the following information to the callee and/or in an 
Invite message: 

• Session name and purpose 

• Time the session is active 

• The media comprising the session 

• Information to receive those media, etc. 

A session description consists of a session-level description and optionally several media 
level descriptions, wherein the media description includes media name, title, etc., See RFC 
2327 or Handley, [5], [5.1], [6]: SDP specification, reproduced herein. 

"...A session description consists of a session-level description 
(details that apply to the whole session and all media streams) and 
optionally several media-level descriptions (details that apply onto 
to a single media stream). 

An announcement consists of a session-level section followed by zero 
or more media-level sections. The session-level part starts with a 
"v: 1 line and continues to the first media-level section. The media 
description starts with an "m:' line and continues to the next media 
description or end of the whole session description. In general, 
session-level values are the default for all media unless overridden 
by an equivalent media-level value. 

When SDP is conveyed by SAP, only one session description is allowed 
per packet. When SDP is conveyed by other means, many SDP session 
descriptions may be concatenated together (the "v:' line indicating 
the start of a session description terminates the previous 
description). Some lines in each description are required and some 
are optional but all must appear in exactly the order given here (the 
fixed order greatly enhances error detection and allows for a simple 
parser). Optional items are marked with a "*' 



Session description 
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v= (protocol version) 

o= (owner/creator and session identifier). 

s: (session name) 

i=* (session information) 

Handley & Jacobson Standards Track [Page 7] 
RFC 2327 SDP April 1998 

u=* (URI of description) 

e=* (email address) 

p=* (phone number) 

c:* (connection information - not required if included in all media) 
b=* (bandwidth information) 

One or more time descriptions (see below) 

z:* (time zone adjustments) 

k=* (encryption key) 

a=* (zero or more session attribute lines) 

Zero or more media descriptions (see below) 

Time description 

t: (time the session is active) 

r=* (zero or more repeat times) 

Media description 

m= (media name and transport address) 
i=* (media title) 

c:* (connection information - optional if included at session-level) 

b=* (bandwidth information) 

k=* (encryption key) 

a=* (zero or more media attribute lines) 



Stated another way, the SIP Invite request comprises identification of a pre-existing 
playable media file, i.e. media name and/or media title as set forth above, through SDP 
descriptions. 
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In the Brief, e.g. pg. 17, appellant argues that "the combination fails to teach or suggest 
an invite request that includes the claimed "playback option enabling the guest terminal to 
request different types of playback actions in connection with playback of the identified media 
file "...However, careful review of Handley et al. reveals that the "a=sendrecv" field described at 
page 22 is not a playback option enabling the guest wireless terminal to request different types of 
playback actions in connection with playback of a pre-existing playable media file. Rather, the 
"a=sendrecv" instruction merely specifies that tools should be started in a "send and 
receive mode". 

In response to argument above, Examiner respectfully disagrees. 
Independent claim 1, in part, recites: 

A method comprising: 

receiving a first media playback invite request initiated by a host wireless terminal, the first 
media playback invite request including 

information sufficient to identify at least one guest wireless terminal, 
an identification of a pre-existing playable media file, and 
a playback option enabling the guest wireless terminal to request different 
types of playback actions in connection with playback of the identified media file 

Claim Interpretation 

The limitation recites "the invite request... including a playback option enabling the 
guest terminal to request different types of playback actions. 

The term "enabling" and/or "enable" is defined as a command or condition that 
permits some specific event to occur, or a command or condition that permits some specific 
event to proceed, See The Authoritative Dictionary of IEEE Standards Terms, Seventh 
Edition, pg. 378. 
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In view of this definition, the recitation suggests that the playback option allows/permits 
the guest terminal to request different types of action requests. 

Note that as per appellant's specification, which is reproduced above, the playback 
option enabling the user to request different types of playback actions comprises requesting one 
of a number of action types during the playback session, including pause playback, rewind, 
fast-forward, user- specified internal effect algorithm to modify audio or video (e.g. 
altering the audio and video in order to accentuate a favorite actress), or textual comment 
from a user. As an example: appellant discloses that "if a user wishes to send a comment to 
the other users, an action request message with textual comment e.g. I really like this 
scene... is sent to the central server. 



In RFC 2327, Handley discloses an example SDP description, e.g. pg. 7-8: 



v=0 

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 
s=SDP Seminar 

i:A Seminar on the session description protocol 
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp. 03.ps 
e=mjh@isi.edu (Mark Handley) 
c=IN IP4 224.2.17.12/127 

Handley & Jacobson Standards Track [Page 8] 
RFC 2327 SDP April 1998 

1=2873397496 2873404696 
a=recvonly 

maudio 49170 RTP/AVP 0 
m: video 51372 RTP/AVP 31 
mapplication 32416 udp wb 
a:orient:portrait 



Handley, atpg. 17-18, further discloses: 



Attributes 
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a= 
a=: 

Attributes are the primary means for extending SDP. Attributes may 
be defined to be used as "session-level" attributes, "media-level" 
attributes, or both. 

A media description may have any number of attributes ("a:" fields) 
which are media specific. These are referred to as "media-level" 
attributes and add information about the media stream. Attribute 
fields can also be added before the first media field; these 
"session-level" attributes convey additional information that applies 
to the conference as a whole rather than to individual media; an 
example might be the conference's floor control policy. 

Attribute fields may be of two forms: 

o property attributes. A property attribute is simply of the form 
"a:". These are binary attributes, and the presence of the 
attribute conveys that the attribute is a property of the session. 
An example might be "a:recvonly". 

o value attributes. A value attribute is of the form 
"a::". An example might be that a whiteboard 
could have the value attribute "a:orient:landscape" 

Attribute interpretation depends on the media tool being invoked. 
Thus receivers of session descriptions should be configurable in 
their interpretation of announcements in general and of attributes in 
particular. 



And, at pg. 22-23, Handley further discloses: 
a=recvonly 

This specifies that the tools should be started in receive-only 

mode where applicable. It can be either a session or media 
attribute, and is not dependent on charset. 

a:sendrecv 

This specifies that the tools should be started in send and 
receive mode. This is necessary for interactive conferences with 
tools such as wb which defaults to receive only mode. It can be 
either a session or media attribute, and is not dependent on 
charset. 

a:sendonly 

This specifies that the tools should be started in send-only 

mode. An example may be where a different unicast address is to 



Application/Control Number: 10/017,654 
Art Unit: 2451 



Page 31 



be used for a traffic destination than for a traffic source. In 
such a case, two media descriptions may be use, one sendonly and 
one recvonly. It can be either a session or media attribute, but 
would normally only be used as a media attribute, and is not 
dependent on charset. 

a:orient: 

Normally this is only used in a whiteboard media specification. 
It specifies the orientation of a the whiteboard on the screen. 
It is a media attribute. Permitted values are "portrait", 
"landscape' and "seascape' (upside down landscape). It is not 
dependent on charset 



Clearly, the "a=recvonly", "a=sendrecv" and "a=sendonly" options 
enables/allows/permits and/or disables/disallows the guest terminal to send 
data/command/instructions enabled by the "a=xxxx" option. 

Clearly, the "a" attribute option, which is also media specific, i.e. is in connection with 
playback of a pre-existing playable media file, is included within the SDP description in the 
invite message. 

In an event the tools are started in sendonly mode, the host terminal may not allow the 
guest terminal to send any data/requests/instructions such as comments, requests, etc. 

For example: the guest terminal may not be able/allowed/permitted to send any data, i.e. 
a request for sending data in connection, i.e. with respect to the media file, i.e. a type of action in 
connection with the media file in playback session, such as inputting a comment and attempting 
to send the comment about a media file. 



In an event the tools are started in "sendrecv" mode, the host terminal allows the guest 
terminal to send the data, wherein if the guest terminal can send data implies that the guest 
terminal can send any requests and/or instruction with respect to comments. 
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For example: a:sendrecv 

This specifies that the tools should be started in send and 
receive mode. This is necessary for interactive conferences with 
tools such as wb which defaults to receive only mode. It can be 
either a session or media attribute, and is not dependent on 
charset. 

This option enables the computers to send and receive data and/or information. In other 
words, it enables the callee computer to send the different types of actions associated with a tool, 
such as wb for interactive conferences. (Note that appellant specification suggests the action 
request to include inputting a comment and sending the comment, i.e. data). 

The term "interaction" means both the host and guest can participates in a session 
collaboratively. In Other words, both the host and guest can send data, request, comments, 
actions, instructions, etc. 

For example: If a host and guest are engaged in an online meeting or collaboration, e.g. 
Handley, pg. 23. In this case, the "sendrecv" only mode enables the guest terminal to send data 
with respect to or in connection to media file such as slides, etc., wherein the data may comprise 
questions, answers, comments, actions, requests, etc., which are typical processes in a meeting. 
(Note that appellant specification suggests the action request to include inputting a comment and 
sending the comment, i.e. data). 

Moreover, In the written description, e.g. pg. 7 [25], applicant discloses: 

"...In one variation, invite request comprises various fields, including guest user id, session id, media file 
id, host user id, playback options, playback scheduling, and a free text string of other media type that explains the 
invitation to the guest users. Playback options give specific guest users permission to request different types of 
actions during playback session. . ." 
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In other words, the playback option may allow/disallow the guest users to request 
different types of actions. 

The "a=sendrecv" field in Handley is a playback option that is associated with the 
playback and/or synchronization of media and is a media specific, which enables and/or allows 
the callee computer to send and receive data including requesting different types of actions. One 
of the "a=..." field denies the guest users to request different types of actions, i.e. denies the 
users to send any data or requests. 

Furthermore, appellant acknowledges that "Instead, Handley indicates that... should be 
started in "send and receive mode", e.g. The Brief, pg. 18. 

The send and receive mode enables and/or gives the callee the permissions to receive and 
send the data. The data can include requesting different types of action/requests such as inputting 
a comment in connection to or regarding a media file. 

In fact, appellant specification also suggests conveying the playback option as a mode, 
e.g. specification, pg. 8-9 [26]. 

Furthermore, the claim recites "...a playback option enabling the guest wireless terminal 
to request different types of playback actions in connection. . .". 

It appears that the recitation "to request different types of..." is a latent property or an 

additional advantage which would flow naturally from following the suggestion of the prior art. 

For example: if the guest terminal cannot send data implies that the guest terminal cannot send 

any requests and/or instructions. 

Mere recognition of latent properties in the prior art does not render nonobvious an otherwise known 
invention. In re Wiseman, 596 F.2d 1019, 201 USPQ 658 (CCPA1979) (Claims were directed to grooved carbon 
disc brakes wherein the grooves were provided to vent steam or vapor during a braking action. A prior art reference 
taught noncarbon disc brakes which were grooved for the purpose of cooling the faces of the braking members and 
eliminating dust. The court held the prior art references when combined would overcome the problems of dust and 
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overheating solved by the prior art and would inherently overcome the steam or vapor cause of the problem relied 
upon for patentability by applicants. Granting a patent on the discovery of an unknown but inherent function (here 
venting steam or vapor) "would re -move from the public that which is in the public domain by virtue of its inclusion 
in, or obviousness from, the prior art." 596 F.2d at 1022, 201 USPQ at 661.); In re Baxter Travenol Labs., 952 F.2d 
388, 21 USPQ2d 1281 (Fed. Cir. 1991) (Appellant argued that the presence of DEHP as the plasticizer in a blood 
collection bag unexpectedly suppressed hemolysis and therefore rebutted any prima facie showing of obviousness, 
however the closest prior art utilizing a DEHP plasticrzed blood collection bag inherently achieved same result, 
although this fact was unknown in the prior art.). 

"The fact that appellant has recognized another advantage which would flow naturally from following the 
suggestion of the prior art cannot be the basis for patentability when the differences would otherwise be obvious." 
Ex parte Obiaya, 227 USPQ 58, 60 (Bd. Pat. App. & Inter. 1985) (The prior art taught combustion fluid analyzers 
which used labyrinth heaters to maintain the samples at a uniform temperature. Although appellant showed an 
unexpectedly shorter response time was obtained when a labyrinth heater was employed, the Board held this 
advantage would flow naturally from following the suggestion of the prior art.). See also Lantech Inc. v. Kaufman 
Co. of Ohio Inc., 878 F.2d 1446, 12 USPQ2d 1076, 1077 (Fed. Cir. 1989), cert, denied, 493 U.S. 1058 (1990) 
(unpublished — not citable as precedent) ("The recitation of an additional advantage associated with doing what the 
prior art suggests does not lend patentability to an otherwise unpatentable invention."). 

In re Lintner, 458 F.2d 1013, 173 USPQ 560 (CCPA 1972) and In re Dillon, 919 F.2d 688, 16 USPQ2d 
1897 (Fed. Cir. 1990) discussed in MPEP § 2144 are also pertinent to this issue. See MPEP 2145 II. 



In the Brief, e.g. pg. 18, appellant asserts "However, the Examiner points to no evidence 
that Handley et al. relate to playback of a pre-existing playable media file". 

First, Liou clearly discloses playback of a pre-existing playable media file, e.g. fig. 10 
and pg. 18 line 4 to pg. 19 line 13. 

Secondly, Dalrymple discloses using a SIP protocol to invite participants to join a session 
and/or engage in a session, See fig. 2. 

As set forth above, the SIP protocol uses SDP to provide session descriptions. The SDP 
set forth above identifies the media file . Obviously, the media file is pre-existing at certain 
location. 

In the Brief, e.g. pg. 19, appellant asserts that "While the claim recitation of. ..may not 
require the pre-existing playable media file to be specifically at the guest wireless terminal, it is 
clear that when this portion... the pre-existing media file must be at the guest wireless terminal. 
The whole point of invite request and the acceptance of the invite request is to determine if the 



Application/Control Number: 1 0/0 1 7,654 Page 35 

Art Unit: 2451 

guest wishes to accept the invitation and, if so, does the media file exist at the guest wireless 
terminal. If the media file does not exist at that location, then the guest terminal will request 
download of that media file before acceptance of the invite request. . ." 

In response to applicant's argument that the references fail to show certain features of 
applicant's invention, it is noted that the features upon which applicant relies (i.e., "the file must 
be at the guest wireless terminal. . .") are not recited in the rejected claim(s). Although the claims 
are interpreted in light of the specification, limitations from the specification are not read into the 
claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). 
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Appellant implies that when the above information portion of the claim is read in totality 
with other portions of the claim, e.g. "relaying a media playback accept response..." the pre- 
existing media file must be at the guest wireless terminal..." 

In a similar way, when the combinations of references are read together, the pre-existing 
media file must be located at the guest terminal. In any event, Liou clearly teaches that the pre- 
existing media file is located at the guest terminal, See Liou, fig. 10 and pg. 18 line 4 to pg. 19 
line 13. 

Furthermore, appellant alleges that "the whole point of invite request and the acceptance 
of the invite request is to determine if the guest wishes to accept the invitation and, if so, does the 
media file exist at the guest terminal..." 

First, both the specification and/or claims fail to teach and/or suggest applicant's point. 

Secondly, the whole point of invite request is to enable the host terminals to invite the 
participants and enable the participants to join or engage in a session, See RFC 2543: SIP 
protocol, pg. 14 [1.4.4]. 

Appellant also asserts that "if the pre-existing media file was not, or did not need to be, at 
the guest terminal, there would be no need for distributing a start playback request from the host 
wireless terminal to the guest terminal, wherein the start playback request directs the guest 
wireless terminal to begin a playback session of the identified media file in synchronization with 
a beginning of the playback session at the host wireless terminal". e.g. The Brief, pg. 20. 

Examiner, in a similar manner, points out that if the pre-existing media file was not, or 
did not need to be at the user 1 or user 2 of Liou, there would be no need for distributing a start 
playback request directing the one of the terminal to begin a playback session of the identified 
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media file in synchronization with a beginning of the playback session at the host terminal. See 
Liou, fig. 10. 

Moreover, it appears that applicant is addressing the prima facie case of obviousness 
[based on the combination of references] by attacking the references individually. MPEP 2145 
(IV) dearly sets forth: One cannot show nonobviousness by attacking references individually 
where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 
1986). 

For example: Appellant is ignoring and/or disregarding the teachings of Liou and 
Dalrymple, and attacks the Handley reference for pre-existing media file when Liou and 
Dalrymple clearly discloses pre-existence of the media file. 

As such, it is believed that the combination of references discloses each and every 
limitation of claim 1 , and a proper prima facie case of obviousness has been established. 
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c. None of the applied references provides for a media playback invite request 
including playback option enabling the guest terminal to request different types of 
playback actions in connection with playback of the identified media file (The Brief, pg. 
20-21 C). 

In response to argument [c], Examiner respectfully disagrees for the same reasons as set 
forth above. 

Stated another way, Kumar discloses the session description protocol in sending an 
announcement including playback option such as sendrecv, e.g. fig. 6 item #650 and col. 10 LI 1- 
44. 

This sendrecv option is equivalent to the sendrecv option set forth above with respect to 
Handley, thus, the response set forth above applies here as well. 

As per "pre-existing playable media file", Liou in view of Dalrymple discloses sending 
an invitation request message wherein the invitation includes session description including an 
identification of a pre-existing media file, e.g. Dalrymple: fig. 2: SIP Invite request message, 
Wherein SIP uses SDP for session description and SDP includes the media file name and title as 
set forth above. 
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d. Additionally, even if the Honorable Board deems independent claim 3 6... claim 39 
is separately patentable. Claim 39 recites "modifying the identified media file in 
accordance with a modification file during the playback session" (The Brief, pg. 22: 3 rd 
paragraph). 

In response to argument [d], Examiner respectfully disagrees. 
Dependent claim 39 recites: 

The apparatus of claim 36, wherein the processor includes executable instructions to perform: 
modifying the identified media file in accordance with a modification file during the playback session. 



Appellant's specification discloses: 



[42] It is assumed that terminals 101,103, and 105 can fully utilize the selected media file. 
However, this may not be the case. With a plurality of terminals participating in the playback 
session, the terminals may have different capabilities. For example, the playback session may be 
processing a movie having both audio and video components. One of terminals (e.g. terminal 105) 
may have only audio capability while terminals 103 and 103 have both audio and video 
capabilities. Moreover, the active users in the playback session may desire to modify the 
media fde in order to accentuate the viewing experience. 

[43] According to one embodiment, the playback device associated with each of terminals 
101, 103, and 105 is able to modify media characteristics, using a preset selection of effects 
and modifications (e.g. converting color imagery into black and white, inverting the colors, 
distorting the sound channels, changing the tempo and speed of the playback) stored at the 
terminal. In other words, a playback device utilizes a data file containing associated 
modifications in order to alter the processing of the media file during the playback session. 
[46]... modification file... modification functions... 



As one example, the appellant's specification discloses changing the speed of the 
playback during a playback session of the media file in accordance with a data file, i.e. data file 
contains the modifications or functions, e.g. instructions or commands for changing the speed, 
etc. 

Liou explicitly discloses changing the video play speed during a playback session of a 
video content, e.g. col. 8 L7-32, fig. 4: video player including modification file such as 
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annotation control file having annotation functions, attached tools, frame rate file having frame 
rate control functionality, etc. 

As such, Liou discloses modifying the identified media file, i.e. media file in playback 
session such as video content, in accordance with a modification file, i.e. a file that provides 
modifications. A user through the interface providing various tools can change the speed and 
annotate the video, e.g. pg. 1 1 lines 21-32, which shows changing the speed through the interface 
and/or modification file, pg. 12 line 13-25: user typing the text string on the video frame through 
a pop up text edit window, etc. 

e. No adequate rationale for making the various combinations has been established 
(The Brief, pg. 24 E.). The Examiner has not provided an adequate motivation for 
combining the references (pg. 25). 

In response to applicant's argument that there is no suggestion to combine the references, 
the examiner recognizes that obviousness can only be established by combining or modifying the 
teachings of the prior art to produce the claimed invention where there is some teaching, 
suggestion, or motivation to do so found either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 
USPQ2d 1596 (Fed. Cir. 1988)and/« re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). 

In the Brief, e.g. pg. 25, appellant asserts that "For example. ..the examiner asserts that it 
would have been obvious... (Final office action - page 15). However, Liou et al already sets up a 
collaborative session, so there would have been nothing to suggest to the. . ." 
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The motivation in the final office action - page 15 is: 

One of ordinary skilled in the art would have been motivated because this would have 
established a communication session between two computers through invitations (Dalrymple: 
col. 3 L50 to col. 4 LI 8). 

Stated another way, the invitations invites the users to join or engage in a session 
(Dalrymple: col. 3 L50 to col. 4 LI 8). 

Appellant also asserts that "The examiner... however nothing in the prior art suggests that 
any playback option would be desirable in the system of Liou et al." 

The playback option, i.e. an attribute a:rccvonly, a:sendonly, a:sendrecv explicitly 
enables the tools to be started in receive only mode, where the user is limited/restricted to receive 
only mode; send only mode, where the user is limited/restricted to send only mode; and 
send/receive mode, where the users can send and receive data for interactive communications, 
See Handleypg 23. 

This option enables the host to control the communications. For example: If the host 
wants to interactively communicate with the participants, the host can enable interactive 
communications through a:sendrecv mode. 

Appellant further asserts that "Yet, there is no evidence that the skilled artisan would 
have been led by anything... to modify... make an additional modification based on teachings of 
an IP communication in a cellular system". 

The mobile communications enables the users to engage in a communication from any 
remote location using the mobile device. 
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Vilander discloses setting up a connection session between a wireless calling party and 
the wireless called party using the SIP protocol, e.g. col. 2 L59-67. 

As set forth in the RFC 2543: SIP protocol, the protocol enables inviting the participants 
to join and/or engage in a session. 

As such, it would have been obvious to a person of ordinary skilled in the art at the time 
the invention was to modify Liou, Dalrymple, Handley in view of Vilander in order to enable 
communications between the mobile calling party and the mobile called party. 

One of ordinary skilled in the art would have been motivated because it would enabled 
users to participate in a communication session using the mobile devices, See also Dalrymple: 
col. 3 L50 to col. 4 L21, Vilander: col. 2 L59-67, col. 4 L60-67. 

f. These allegations of obviousness by the Examiner amount to a classic case of 
impermissible hindsight... (The Brief, pg. 26). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 

Moreover, the rationale supporting the combination can be found in KSR Ruling. 
See KSR International Co. v. Teleflex Inc., 550 U.S. , , 82 USPQ2d 1385, 1395-97 
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(2007) identified a number of rationales to support a conclusion of obviousness which are 
consistent with the proper "functional approach" to the determination of obviousness as laid 
down in Graham. The key to supporting any rejection under 35 U.S.C. 103 is the clear 
articulation of the reason(s) why the claimed invention would have been obvious. The Supreme 
Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be made 
explicit, and MPEP 2143. [ EXEMPLARY RATIONALES: 

Exemplary rationales that may support a conclusion of obviousness include: 

(A) Combining prior art elements according to known methods to yield predictable results; 

(B) Simple substitution of one known element for another to obtain predictable results; 

(C) Use of known technique to improve similar devices (methods, or products) in the same way; 

(D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable 
results; 

(E) "Obvious to try" - choosing from a finite number of identified, predictable; 

(F) Known work in one field of endeavor may prompt variations of it for use in either the same field or a different 
one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the 
art; 

(G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the 
prior art reference or to combine prior art reference teachings to arrive at the claimed invention. See MPEP § 2143 
for a discussion of the rationales listed above along with examples illustrating how the cited rationales may be used 
to support a finding of obviousness ]. 



For example: In this case, rationale A, B, C, D and/or G applies. 

Stated another way, the claims on the appeal are mere combination of prior art elements, 
which results in a predictable results such as inviting the guest users to participate or engage in a 
session, enabling the guest users to send data/instruction/requests during the session and enabling 
the wireless users to participate in the session in a wireless manner and/or enabling the users to 
participate in the session through mobile devices. 
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(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 

Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 

Respectfully submitted, 

Kamal Divecha 
Art Unit 2451 

Conferees: 
/John Follansbee/ 

Supervisory Patent Examiner, Art Unit 245 1 
/Jeffrey Pwu/ 

Supervisory Patent Examiner, Art Unit 2446 



